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Description 
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Cross Reference to Related Applications 

[0001] The present application is related to and claims the bene- 
fit of priority of the following commonly-owned, 
presently-pending provisional application(s): application 
serial no. 60/481,679 (Docket No. VIV/0014.00), filed 
November 20, 2003, entitled "System Providing Methodol- 
ogy for Access Control with Cooperative Enforcement", of 
which the present application is a non-provisional appli- 
cation thereof. The present application is related to and 
claims the benefit of priority of the following commonly- 
owned, presently-pending nonprovisional application(s): 
application serial no. 09/944,057 (Docket No. VIV/ 
0003.01), filed August 30, 2001, entitled "System Provid- 
ing Internet Access Management with Router-based Policy 
Enforcement", of which the present application is a Con- 



tinuation-in-part application thereof; application serial 
no. 10/249,073 (Docket No. VIV/0010.01), filed March 
13, 2003, entitled "System and Methodology for Policy En- 
forcement", of which the present application is a Continu- 
ation-in-part application thereof. The disclosures of each 
of the foregoing applications are hereby incorporated by 
reference in their entirety, including any appendices or at- 
tachments thereof, for all purposes. 
Copyright Statement 

[0002] a portion of the disclosure of this patent document con- 
tains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile re- 
production by anyone of the patent document or the 
patent disclosure as it appears in the Patent and Trade- 
mark Office patent file or records, but otherwise reserves 
all copyright rights whatsoever. 
Appendix Data 

[0003] Computer Program Listing Appendix under Sec. 1.52(e): 
This application includes a transmittal under 37 C.F.R. 
Sec. 1.52(e) of a Computer Program Listing Appendix. The 
Appendix, which comprises text file(s) that are IBM-PC 
machine and Microsoft Windows Operating System com- 



patible, includes the below-listed file(s). All of the mate- 
rial disclosed in the Computer Program Listing Appendix 
can be found at the U.S. Patent and Trademark Office 
archives and is hereby incorporated by reference into the 
present application. 
[0004] object Description: SourceCode.txt created: 11/20/2003, 
8:37am, size: 67.9KB; Object ID: File No. 1; Object Con- 
tents: Source Code. 
Background of Invention 

[0005] i. Field of the Invention 

[0006] The present invention relates generally to systems and 
methods for maintaining security of computer systems 
connected to one or more networks (e.g., Local Area Net- 
works or Wide Area Networks) and, more particularly, to a 
system providing methodology for access control with co- 
operative enforcement. 

[0007] 2. Description of the Background Art 

[0008] The first computers were largely stand-alone units with 

no direct connection to other computers or computer net- 
works. Data exchanges between computers were mainly 
accomplished by exchanging magnetic or optical media 
such as floppy disks. Over time, more and more comput- 



ers were connected to each other using Local Area Net- 
works or LANs. In both cases, maintaining security and 
controlling what information a computer user could ac- 
cess was relatively simple because the overall computing 
environment was limited and clearly defined. 
[0009] with the ever-increasing popularity of the Internet, how- 
ever, more and more computers are connected to larger 
networks. Providing access to vast stores of information, 
the Internet is typically accessed by users through Web 
"browsers" (e.g., Microsoft® Internet Explorer or Netscape 
Navigator) or other Internet applications. Browsers and 
other Internet applications include the ability to access a 
URL (Universal Resource Locator) or "Web" site. In the last 
several years, the Internet has become pervasive and is 
used not only by corporations, but also by a large number 
of small businesses and individual users for a wide range 
of purposes. Many applications are now Web-enabled, 
providing services to remote users through various types 
of networks. 

[0010] As more and more computers are now connected to other 
local and remote computers (e.g., via the Internet), a 
whole new set of challenges face system administrators 
and individual users alike: these previously closed com- 



puting environments are now open to a worldwide net- 
work of computer systems. A particular set of challenges 
involves attacks by perpetrators (hackers) capable of 
damaging the local computer systems, misusing those 
systems, and/or stealing proprietary data and programs. 
Another challenge is in maintaining and securing applica- 
tions (services) that are made available to remote users. 
1 ] A service is a unit of program logic (e.g., an application or 
process) which runs on a remote computer or in the back- 
ground on a local computer and provides data to and/or 
performs tasks for other programs (e.g., application pro- 
grams). The work performed or offered by a service may 
include simply serving simple requests for data to be sent 
or stored or it may involve more complex tasks. A well 
known example of a service that is currently in wide use is 
the domain name service (DNS). The domain name service 
resolves a URL name to an IP address (and vice versa). An- 
other example of a service is an FTP (file transfer protocol) 
service for transfer of files. Historically, using a service 
has involved calling a remote server to obtain data and/or 
work from the remote server. However, as computers have 
become more powerful, a typical computer environment 
also includes services that are available locally. 



[0012] Currently, most computer services (i.e., server programs 
in a client-server scheme) grant access to remote com- 
puters based on user authentication. In multiprocessing 
systems, they do the same thing for other processes on 
the same computer. For the purposes of the following dis- 
cussion, both of these situations will be referred to as 
"client/server" computing, where the "client" is a user/ 
program attempting to access a "server" to use a particu- 
lar service (e.g., an application or service on a remote 
computer). 

[0013] once a client (e.g., user) is authenticated to have access, 
these services typically assign access privileges to each 
user or group of users. Depending on the function of the 
program, the set of access privileges can vary. For file 
system service programs (e.g., Netbios, SAMBA, and other 
file sharing systems), access rights include the ability to 
read, write, execute files, and create or delete files in di- 
rectories. For Web servers, access rights include the ability 
to execute specific access verbs (e.g., GET, POST, etc.) to 
specific URLs. For a sales transaction system, access rights 
may include the ability to register a sale, to perform a re- 
fund, to report the day's tally, and so on. 

[0014] Access privilege to a given resource is often specified as 



an access control list (ACL) associated with a specific re- 
source by the operating system or a service application. 
An ACL names users and groups, and the list of access 
rights each is assigned. ACLs also list the access rights (if 
any) of users who are not members of any of the listed 
groups. 

[0015] Although current user authentication systems are widely 
used to control access to computer systems and networks, 
several problems remain. One problem that is not ad- 
dressed by current user authentication systems is ensur- 
ing that all devices that connect to a service or resource 
comply with applicable security policies in order to protect 
these services and resources. For example, if a remote 
user that is connected to a bank for on-line banking does 
not apply and enforce the bank's required security poli- 
cies, a hacker could gain unauthorized access to the 
bank's systems through the remote user's unsecured sys- 
tem. Although a secure connection may be established 
between the bank and the user, and the user may be au- 
thenticated for access to the bank's systems, if the user's 
system is vulnerable to any security breaches the security 
of the overall environment may be jeopardized. 

[0016] a related problem is that if a client device is infected with 



a virus or worm, it may infect other machines to which it 
is connected. For example, an infected computer that is 
connected to a particular network (e.g., a corporate LAN) 
may be infected with a virus that intentionally tries to 
spread itself to other machines. One machine that is not 
running the correct anti-virus engine or is not equipped 
with current virus signature definition files may jeopardize 
the security of many other machines. Ensuring that con- 
nected client devices are running current anti-virus pro- 
grams is particularly important, as virus suppression 
methods are very time sensitive and failure to use current 
anti-virus programs may result in the introduction of a 
virus that can cause significant damage. 
[0017] a solution is required that validates access and assigns 
access privileges to clients based on credentials in addi- 
tion to user identity. The solution should ensure that 
client devices connecting to services or other resources 
are using appropriate security mechanisms and are other- 
wise in compliance with required security policies to 
maintain the overall security of the environment. In par- 
ticular, the solution should ensure that a client device re- 
questing access to a particular service has appropriate se- 
curity mechanisms and virus suppression measures in- 



stalled and operational before it is permitted to access the 
service. The present invention provides a solution for 
these and other needs. 
Summary of Invention 

[0018] a system providing methodology for access control with 
cooperative enforcement is described. In one embodi- 
ment, for example, a method of the present invention is 
described for authorizing a client to access a service 
based on compliance with a policy required for access to 
the service, the method comprises steps of: specifying a 
policy required for access to the service; detecting a re- 
quest for access to the service from a client; attempting 
authentication of the client based on credentials pre- 
sented by the client; if the client is authenticated based on 
the credentials, determining whether the client is in com- 
pliance with the policy based, at least in part, on at- 
tributes of the client; and if the client is determined to be 
in compliance with the policy, providing access to the ser- 
vice. 

[0019] | n another embodiment, for example, a system of the 

present invention is described for authenticating and as- 
signing access privileges to a client device for access to a 
service, the system comprises: a policy specifying access 



privileges to be assigned to a client device based on at- 
tributes of the client device; a primary authentication 
module for receiving a request from a client device for ac- 
cess to the service and determining whether to authenti- 
cate the client device for access to the service; and a sup- 
plemental authentication module for examining attributes 
of a client device authenticated by the primary authentica- 
tion module and assigning access privileges to the client 
device based on the policy. 

[0020] | n y e t another embodiment, for example, a method of the 
present invention is described for assigning privileges to a 
client to use a service based on an access policy, the 
method comprises steps of: specifying an access policy 
for assigning privileges to a client to use the service based 
on attributes of the client; detecting a request for use of 
the service from a client; attempting authentication of the 
client based on user identity information provided by the 
client; if the client is authenticated based on user identity, 
collecting attribute information from the client; and as- 
signing privileges to the client to use the service based on 
the collected attribute information and the access policy. 

[0021] | n another embodiment, for example, in a system com- 
prising a client computer connecting to a service through 



a network, a method of the present invention is described 
for regulating access to the service based on a specified 
access policy, the method comprises steps of: transmit- 
ting a challenge from the service to the client computer 
connecting to the service for determining whether the 
client computer is in compliance with the specified access 
policy, wherein the access policy includes attributes of the 
client device that are acceptable for permitting access to 
the service; transmitting a response from the client com- 
puter back to the service, for responding to the challenge 
issued by the service; and blocking access to the service 
by the client computer if the client computer does not re- 
spond appropriately to the challenge issued by the ser- 
vice. 

Brief Description of Drawings 

[0022] pig. 1 is a very general block diagram of a computer sys- 
tem (e.g., an IBM-compatible system) in which software- 
implemented processes of the present invention may be 
embodied. 

[0023] pig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system. 

[0024] Fig. 3 is a block diagram of an environment in which the 
present invention may be embodied. 



[0025] pig. 4 is a block diagram illustrating in more detail an en- 
vironment in which the present invention is implemented 
using sub-authentication filters in a Windows environ- 
ment. 

[0026] pigs. 5A-B comprise a single flowchart illustrating the op- 
eration of the present invention in authenticating a client 
attempting to access an application or service (e.g., on an 
application server). 

[0027] Figs. 6A-B comprise a single flowchart illustrating the op- 
erations of the present invention in authenticating a client 
accessing a service in a Kerberos implementation. 

[0028] Fig. 7 is a block diagram illustrating an environment in 
which the methodology of the present invention may be 
implemented in a Linux, UNIX, or Solaris environment us- 
ing Pluggable Authentication Modules. 

[0029] Figs. 8A-B comprise a single flowchart illustrating the 

process of authenticating a client attempting to access an 
application or service through a separate security evalua- 
tion service. 
Detailed Description 

Glossary 



[0030] The following definitions are offered for purposes of i 1 1 us— 



tration, not limitation, in order to assist with understand- 
ing the discussion that follows. 

[0031] End point security: End point security is a way of manag- 
ing and enforcing security on each computer instead of 
relying upon a remote firewall or a remote gateway to 
provide security for the local machine or environment. End 
point security involves a security agent that resides locally 
on each machine. This agent monitors and controls the 
interaction of the local machine with other machines and 
devices that are connected on a LAN or a larger wide area 
network (WAN), such as the Internet, in order to provide 
security to the machine. 

[0032] Firewall: A firewall is a set of related programs, typically 
located at a network gateway server, that protects the re- 
sources of a private network from other networks by con- 
trolling access into and out of the private network. (The 
term also implies the security policy that is used with the 
programs.) A firewall, working closely with a router pro- 
gram, examines each network packet to determine 
whether to forward it toward its destination. A firewall 
may also include or work with a proxy server that makes 
network requests on behalf of users. A firewall is often in- 
stalled in a specially designated computer separate from 



the rest of the network so that no incoming request di- 
rectly accesses private network resources. 
[0033] GSS-API: The Generic Security Service Application Program 
Interface (GSS-API) provides application programmers 
uniform access to security services using a variety of un- 
derlying cryptographic mechanisms. The GSS-API allows a 
caller application to authenticate a principal identity, to 
delegate rights to a peer, and to apply security services 
such as confidentiality and integrity on a per-message 
basis. Examples of security mechanisms defined for GSS- 
API include "The Simple Public-Key GSS-API Mechanism" 
and "The Kerberos Version 5 GSS-API Mechanism". For 
further information regarding GSS-API, see e.g., "RFC 
2743: Generic Security Service Application Program Inter- 
face Version 2, Update 1", available from the Internet En- 
gineering Task Force (IETF), the disclosure of which is 
hereby incorporated by reference. A copy of RFC 2743 is 
available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc2743.txt). See also e.g., "RFC 2853: 
Generic Security Service API Version 2: Java Bindings", 
available from the IETF, the disclosure of which is hereby 
incorporated by reference. A copy of RFC 2853 is available 
via the Internet (e.g., currently at 



www.ietf.org/rfc/rfc2853.txt). 
[0034] Kerberos: Kerberos is an authentication protocol for veri- 
fying the identities of principals (e.g., a workstation user 
or a network server) on an open network. The Kerberos 
authentication process generally involves the following 
steps. A client sends a request to the authentication 
server (AS) requesting "credentials" for a given server. The 
authentication server responds with these credentials, en- 
crypted to the client's key. The credentials consist of: 1) a 
"ticket" for the server; and 2) a temporary encryption key 
(often called a "session key"). The client transmits the 
ticket (which contains the client's identity and a copy of 
the session key, all encrypted to the server's key) to a 
server (e.g., an application server). The session key (now 
shared by the client and the server) is used to authenticate 
the client, and may optionally be used to authenticate the 
server. It may also be used to encrypt further communica- 
tion between the two parties or to exchange a separate 
sub-session key to be used to encrypt further communi- 
cation. Atypical Kerberos implementation consists of one 
or more authentication server(s) running on physically se- 
cure hosts. The authentication server(s) maintain a 
database of principals (i.e., users and servers) and their 



secret keys. Code libraries provide encryption and imple- 
ment the Kerberos protocol. In order to add authentica- 
tion to its transactions, a typical network application adds 
one or two calls to the Kerberos library, which results in 
the transmission of the necessary messages to achieve 
authentication. For further description of Kerberos au- 
thentication, see e.g., "RFC 1510 - The Kerberos Network 
Authentication Service (V5)", available from the IETF, the 
disclosure of which is hereby incorporated by reference. A 
copy of RFC 1510 is available via the Internet (e.g., cur- 
rently at www.ietf.org/rfc/rfcl510.txt). Also see e.g., "RFC 
1964 - The Kerberos Version 5 GSS-API Mechanism", 
available from the IETF, the disclosure of which is hereby 
incorporated by reference. A copy of RFC 1964 is available 
via the Internet (e.g., currently at 
www.ietf.org/rfc/rfcl964.txt). 
[0035] MD5: MD5 is a message-digest algorithm which takes as 
input a message of arbitrary length and produces as out- 
put a 128-bit "fingerprint" or "message digest" of the in- 
put. The MD5 algorithm is used primarily in digital signa- 
ture applications, where a large file must be "compressed" 
in a secure manner before being encrypted with a private 
(secret) key under a public-key cryptosystem. Further de- 



scription of MD5 is available in "RFC 1321: The MD5 Mes- 
sage-Digest Algorithm", (April 1992), the disclosure of 
which is hereby incorporated by reference. A copy of RFC 
1321 is available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfcl321.txt). 

[0036] Network: A network is a group of two or more systems 
linked together. There are many types of computer net- 
works, including local area networks (LANs), virtual private 
networks (VPNs), metropolitan area networks (MANs), 
campus area networks (CANs), and wide area networks 
(WANs) including the Internet. As used herein, the term 
"network" refers broadly to any group of two or more 
computer systems or devices that are linked together 
from time to time (or permanently). 

[0037] PAM: PAM stands for Pluggable Authentication Modules 

which can be used to assign specific authentication meth- 
ods to specific services in an environment running Linux, 
UNIX, and/or Solaris operating systems. With the Plug- 
gable Authentication Module (PAM) framework, multiple 
authentication technologies can be added without chang- 
ing any of the login services, thereby preserving existing 
system environments. PAM modules can be used to inte- 
grate login services with different authentication tech- 



nologies, such as RSA, DCE, Kerberos, S/Key, and smart 
card based authentication systems. Thus, Pluggable Au- 
thentication Modules enable networked machines to exist 
in a heterogeneous environment, where multiple security 
mechanisms are in place. For further description of PAM 
modules, see e.g., Samar, V. et al., "Making Login Services 
Independent of Authentication Technologies", available 
from SunSoft, Inc., the disclosure of which is hereby in- 
corporated by reference. A copy of this white paper is 
available via the Internet (e.g., currently at 
wwws.sun.com/software/solaris/pam/pam.external.pdf)- 
[0038] Security policy: In general terms, a security policy is an 
organization's statement defining the rules and practices 
that regulate how it will provide security, handle intru- 
sions, and recover from damage caused by security 
breaches. An explicit and well-defined security policy in- 
cludes a set of rules that are used to determine whether a 
given subject will be permitted to gain access to a specific 
object. A security policy may be enforced by hardware and 
software systems that effectively implement access rules 
for access to systems and information. Further informa- 
tion on security policies is available in "RFC 2196: Site Se- 
curity Handbook, (September 1997)", the disclosure of 



which is hereby incorporated by reference. A copy of RFC 
2196 is available from the IETF via the Internet (e.g., cur- 
rently atwww.ietf.org/rfc/rfc2196.txt). For additional in- 
formation, see also, e.g., "RFC 2704: The KeyNote Trust 
Management System Version 2", the disclosure of which is 
hereby incorporated by reference. A copy of RFC 2704 is 
available from the IETF via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc2704.txt). In this document, "security 
policy" or "policy" refers to a set of security policies and 
rules employed by an individual or by a corporation, gov- 
ernment entity, or any other organization operating a net- 
work or other computing resources. 
[0039] Service: Service refers to work performed or offered by a 
unit of program logic (e.g., a program or process). A ser- 
vice is an abstract resource that represents a capability of 
performing tasks that form a coherent functionality from 
the point of view of providers entities and requester enti- 
ties. To be used, a service must be realized by a concrete 
provider entity, which is usually referred to as the 
"provider" or "server". The service performs tasks for an- 
other program or process which is typically referred to as 
the "requester" or "client". The tasks that are performed 
may include serving simple requests for data to be sent or 



stored or may include more complex work. Examples of 
services that perform tasks for other programs include 
domain name services and Web services (defined below). 

[0040] SSL: SSL is an abbreviation for Secure Sockets Layer, a 
protocol developed by Netscape for transmitting private 
documents over the Internet. SSL works by using a public 
key to encrypt data that is transferred over the SSL con- 
nection. Both Netscape Navigator and Microsoft Internet 
Explorer support SSL, and many Web sites use the proto- 
col to obtain confidential user information, such as credit 
card numbers. SSL creates a secure connection between a 
client and a server, over which data can be sent securely. 
For further information, see e.g., "The SSL Protocol, ver- 
sion 3.0", (November 18, 1996), from the IETF, the disclo- 
sure of which is hereby incorporated by reference. See 
also, e.g., "RFC 2246: The TLS Protocol, version 1.0", 
available from the IETF. A copy of RFC 2246 is available 
via the Internet (e.g., currently at 
www.itef.org/rfc/rfc2246.txt). 

[0041] TCP: TCP stands for Transmission Control Protocol. TCP is 
one of the main protocols in TCP/IP networks. Whereas 
the IP protocol deals only with packets, TCP enables two 
hosts to establish a connection and exchange streams of 



data. TCP guarantees delivery of data and also guarantees 
that packets will be delivered in the same order in which 
they were sent. For an introduction to TCP, see e.g., "RFC 
793: Transmission Control Program DARPA Internet Pro- 
gram Protocol Specification", the disclosure of which is 
hereby incorporated by reference. A copy of RFC 793 is 
available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc793.txt). 

[0042] TCP/IP: TCP/IP stands for Transmission Control Protocol/ 
Internet Protocol, the suite of communications protocols 
used to connect hosts on the Internet. TCP/IP uses several 
protocols, the two main ones being TCP and IP. TCP/IP is 
built into the UNIX operating system and is used by the 
Internet, making it the de facto standard for transmitting 
data over networks. For an introduction to TCP/IP, see 
e.g., "RFC 1180: A TCP/IP Tutorial," the disclosure of 
which is hereby incorporated by reference. A copy of RFC 
1180 is available via the Internet (e.g., currently at 
www . i e tf . o rg / rf c / rf c 1 1 8 0 . txt) . 

[0043] TNT: The Trust Negotiation in TLS (TNT) protocol is an ex- 
tension to the TLS handshake protocol that incorporates 
trust negotiation into TLS to provide advanced client/ 
server authentication in TLS. Many business transactions 



on the Internet occur between "strangers", that is, be- 
tween entities with no prior relationship and no common 
security domain. Traditional security approaches based on 
identity or capabilities do not solve the problem of estab- 
lishing trust between strangers. One new approach to 
mutual trust establishment is trust negotiation, the bilat- 
eral exchange of digital credentials to establish trust 
gradually. The TNT protocol provides confidential trust 
negotiation, verification of private keys during trust nego- 
tiation, and a single trust negotiation protocol supporting 
interoperable trust negotiation strategies. For further de- 
scription of TNT, see e.g., Hess, A. et al., "Advanced 
Client/Server Authentication in TLS", in Proceedings of 
Network and Distributed System Security Symposium, San 
Diego, CA, February 2002, the disclosure of which is 
hereby incorporated by reference. 
[0044] UDP: UDP stands for User Datagram Protocol, a connec- 
tionless protocol that, like TCP, runs on top of IP net- 
works. Unlike TCP/IP, UDP/IP provides very few error re- 
covery services, offering instead a direct way to send and 
receive datagrams over an IP network. UDP is used pri- 
marily for broadcasting messages over a network. For ad- 
ditional information on UDP, see RFC 768, "User Datagram 



Protocol", the disclosure of which is hereby incorporated 
by reference. A copy of RFC 768 is available via the Inter- 
net (e.g., currently at www.ietf.org/rfc/rfc768.txt). 

[0045] web Service: A Web service is a software program or sys- 
tem designed to support interoperable machine- 
to-machine interaction over a network. A Web service has 
an interface described in a machine-processable format 
(e.g., using Web Services Description Language (WSDL)). 
Other programs and systems interact with the Web service 
in a manner prescribed by its description (e.g., using 
SOAP-messages, typically conveyed using HTTP with an 
XML serialization in conjunction with other Web-related 
standards). A familiar example of an externalized Web 
service is a weather portlet that one can integrate into a 
Web browser. Web services can also be used to encapsu- 
late information and operations. Web services are becom- 
ing widely used for enterprise information exchange and 
as resources for information. 

[0046] XML: XML stands for Extensible Markup Language, a spec- 
ification developed by the World Wide Web Consortium 
(W3C). XML is a pared-down version of the Standard Gen- 
eralized Markup Language (SGML) which is designed es- 
pecially for Web documents. It allows designers to create 



their own customized tags, enabling the definition, trans- 
mission, validation, and interpretation of data between 
applications and between organizations. For further de- 
scription of XML, see e.g., "Extensible Markup Language 
(XML) 1.0", (2nd Edition, October 6, 2000) a recom- 
mended specification from the W3C, the disclosure of 
which is hereby incorporated by reference. A copy of this 
specification is available via the Internet (e.g., currently at 
www.w3.org/TR/2000/REC-xml-20001006). 
Introduction 

[0047] Referring to the figures, exemplary embodiments of the 
invention will now be described. The following description 
will focus on the presently preferred embodiment of the 
present invention, which is implemented in desktop and/ 
or server software (e.g., driver, application, or the like) 
operating in an Internet-connected environment running 
under an operating system, such as the Microsoft Win- 
dows operating system. The present invention, however, 
is not limited to any one particular application or any par- 
ticular environment. Instead, those skilled in the art will 
find that the system and methods of the present invention 
may be advantageously embodied on a variety of different 
platforms, including Macintosh, Linux, Solaris, UNIX, 



FreeBSD, and the like. Therefore, the description of the 
exemplary embodiments that follows is for purposes of il- 
lustration and not limitation. The exemplary embodiments 
are primarily described with reference to block diagrams 
or flowcharts. As to the flowcharts, each block within the 
flowcharts represents both a method step and an appara- 
tus element for performing the method step. Depending 
upon the implementation, the corresponding apparatus 
element may be configured in hardware, software, 
firmware or combinations thereof. 
Computer-based implementation 

[0048] Basic system hardware (e.g., for desktop and server computers) 

[0049] The present invention may be implemented on a conven- 
tional or general-purpose computer system, such as an 
IBM-compatible personal computer (PC) or server com- 
puter. Fig. 1 is a very general block diagram of a com- 
puter system (e.g., an IBM-compatible system) in which 
software-implemented processes of the present invention 
may be embodied. As shown, system 100 comprises a 
central processing unit(s) (CPU) or processor(s) 101 cou- 
pled to a random-access memory (RAM) 102, a read-only 
memory (ROM) 103, a keyboard 106, a printer 107, a 



pointing device 108, a display or video adapter 104 con- 
nected to a display device 105, a removable (mass) stor- 
age device 115 (e.g., floppy disk, CD-ROM, CD-R, CD-RW, 
DVD, or the like), a fixed (mass) storage device 116 (e.g., 
hard disk), a communication (COMM) port(s) or inter- 
face(s) 110, a modem 112, and a network interface card 
(NIC) or controller 111 (e.g., Ethernet). Although not 
shown separately, a real time system clock is included 
with the system 100, in a conventional manner. 
[0050] CPU 101 comprises a processor of the Intel Pentium family 
of microprocessors. However, any other suitable proces- 
sor may be utilized for implementing the present inven- 
tion. The CPU 101 communicates with other components 
of the system via a bi-directional system bus (including 
any necessary input/output (I/O) controller circuitry and 
other "glue" logic). The bus, which includes address lines 
for addressing system memory, provides data transfer be- 
tween and among the various components. Description of 
Pentium-class microprocessors and their instruction set, 
bus architecture, and control lines is available from Intel 
Corporation of Santa Clara, CA. Random-access memory 
102 serves as the working memory for the CPU 101. In a 
typical configuration, RAM of sixty-four megabytes or 



more is employed. More or less memory may be used 
without departing from the scope of the present inven- 
tion. The read-only memory (ROM) 103 contains the basic 
input/output system code (BIOS) — a set of low-level rou- 
tines in the ROM that application programs and the oper- 
ating systems can use to interact with the hardware, in- 
cluding reading characters from the keyboard, outputting 
characters to printers, and so forth. 

[0051] Mass storage devices 115, 116 provide persistent storage 
on fixed and removable media, such as magnetic, optical 
or magnetic-optical storage systems, flash memory, or 
any other available mass storage technology. The mass 
storage may be shared on a network, or it may be a dedi- 
cated mass storage. As shown in Fig. 1, fixed storage 116 
stores a body of program and data for directing operation 
of the computer system, including an operating system, 
user application programs, driver and other support files, 
as well as other data files of all sorts. Typically, the fixed 
storage 116 serves as the main hard disk for the system. 

[0052] | n Das j C operation, program logic (including that which 
implements methodology of the present invention de- 
scribed below) is loaded from the removable storage 115 
or fixed storage 116 into the main (RAM) memory 102, for 



execution by the CPU 101. During operation of the pro- 
gram logic, the system 100 accepts user input from a 
keyboard 106 and pointing device 108, as well as speech- 
based input from a voice recognition system (not shown). 
The keyboard 106 permits selection of application pro- 
grams, entry of keyboard-based input or data, and selec- 
tion and manipulation of individual data objects displayed 
on the screen or display device 105. Likewise, the pointing 
device 108, such as a mouse, track ball, pen device, or the 
like, permits selection and manipulation of objects on the 
display device. In this manner, these input devices sup- 
port manual user input for any process running on the 
system. 

[0053] jhe computer system 100 displays text and/or graphic 
images and other data on the display device 105. The 
video adapter 104, which is interposed between the dis- 
play 105 and the system's bus, drives the display device 
105. The video adapter 104, which includes video memory 
accessible to the CPU 101, provides circuitry that converts 
pixel data stored in the video memory to a raster signal 
suitable for use by a cathode ray tube (CRT) raster or liq- 
uid crystal display (LCD) monitor. A hard copy of the dis- 
played information, or other information within the sys- 



tern 100, may be obtained from the printer 107, or other 
output device. Printer 107 may include, for instance, an 
HP LaserJet printer (available from Hewlett Packard of Palo 
Alto, CA), for creating hard copy images of output of the 
system. 

[0054] The system itself communicates with other devices (e.g., 
other computers) via the network interface card (NIC) 111 
connected to a network (e.g., Ethernet network, Bluetooth 
wireless network, or the like), and/or modem 112 (e.g., 
56K baud, ISDN, DSL, or cable modem), examples of 
which are available from 3Com of Santa Clara, CA. The 
system 100 may also communicate with local occasion- 
ally-connected devices (e.g., serial cable-linked devices) 
via the communication (COMM) interface 110, which may 
include a RS-232 serial port, a Universal Serial Bus (USB) 
interface, or the like. Devices that will be commonly con- 
nected locally to the interface 110 include laptop comput- 
ers, handheld organizers, digital cameras, and the like. 

[0055] IBM-compatible personal computers and server computers 
are available from a variety of vendors. Representative 
vendors include Dell Computers of Round Rock, TX, 
Hewlett-Packard of Palo Alto, CA, and IBM of Armonk, NY. 
Other suitable computers include Apple-compatible com- 



puters (e.g., Macintosh), which are available from Apple 
Computer of Cupertino, CA, and Sun Solaris workstations, 
which are available from Sun Microsystems of Mountain 
View, CA. 

[0056] Basic system software 

[0057] pig. 2 is a block diagram of a software system for control- 
ling the operation of the computer system 100. As shown, 
a computer software system 200 is provided for directing 
the operation of the computer system 100. Software sys- 
tem 200, which is stored in system memory (RAM) 102 
and on fixed storage (e.g., hard disk) 116, includes a ker- 
nel or operating system (OS) 210. The OS 210 manages 
low-level aspects of computer operation, including man- 
aging execution of processes, memory allocation, file in- 
put and output (I/O), and device I/O. One or more appli- 
cation programs, such as client application software or 
"programs" 201 (e.g., 201a, 201b, 201c, 201d) may be 
"loaded" (i.e., transferred from fixed storage 116 into 
memory 102) for execution by the system 100. The appli- 
cations or other software intended for use on the com- 
puter system 100 may also be stored as a set of down- 
loadable computer-executable instructions, for example, 
for downloading and installation from an Internet location 



(e.g., Web server). 

[0058] Software system 200 includes a graphical user interface 
(GUI) 215, for receiving user commands and data in a 
graphical (e.g., "point-and-click") fashion. These inputs, 
in turn, may be acted upon by the system 100 in accor- 
dance with instructions from operating system 210, and/ 
or client application module(s) 201. The GUI 215 also 
serves to display the results of operation from the OS 210 
and application(s) 201, whereupon the user may supply 
additional inputs or terminate the session. Typically, the 
OS 210 operates in conjunction with device drivers 220 
(e.g., "Winsock" driver — Windows' implementation of a 
TCP/IP stack) and the system BIOS microcode 230 (i.e., 
ROM-based microcode), particularly when interfacing with 
peripheral devices. OS 210 can be provided by a conven- 
tional operating system, such as Microsoft Windows 9x, 
Microsoft Windows NT, Microsoft Windows 2000, or Mi- 
crosoft Windows XP, all available from Microsoft Corpora- 
tion of Redmond, WA. Alternatively, OS 210 can also be an 
alternative operating system, such as the previously men- 
tioned operating systems. 

[0059] The above-described computer hardware and software are 
presented for purposes of illustrating the basic underlying 



desktop and server computer components that may be 
employed for implementing the present invention. For 
purposes of discussion, the following description will 
present examples in which it will be assumed that there 
exists one or more "servers" (e.g., Web servers) that com- 
municate with one or more "clients" (e.g., desktop com- 
puters). In multiprocessing systems, a first or "client" pro- 
cess may also obtain services from other processes on the 
same computer. For the purposes of the following discus- 
sion, this situation is also referred to as "client/server" 
computing, where the "client" is a program/process at- 
tempting to access a service provided by another process. 
The present invention, however, is not limited to any par- 
ticular environment or device configuration. In particular, 
a client/server distinction is not necessary to the inven- 
tion, but is used to provide a framework for discussion. 
Instead, the present invention may be implemented in any 
type of system architecture or processing environment ca- 
pable of supporting the methodologies of the present in- 
vention presented in detail below. 
Overview 

[0060] The present invention comprises a system providing 

methodology for validating access and assigning access 



privileges to clients based on credentials in addition to 
user identity. Many services currently grant access privi- 
leges to clients by means of an access policy, which is 
based on client (user) identity only, or on group member- 
ship(s) of the user. The present invention provides for the 
access policy to grant privileges based on additional cre- 
dentials. These additional credentials which are consid- 
ered may, for example, include one or more of the follow- 
ing: security relevant attributes of the client device; loca- 
tion of the user/client device; and/or type of client device. 
The system may also be configured to evaluate various 
other attributes of a client device that may be of interest 
(e.g., whether anti-virus measures and/or file integrity 
policies are in effect at the client device). 
[0061] The approach of the present invention is to implement an 
authentication methodology in which user identity is es- 
tablished and then additional attributes (e.g., security en- 
forcement attributes) are provided by the client (and 
checked for authenticity if possible) for determining 
whether to authenticate a client for access to services 
(e.g., services provided by a remote server computer). On 
the basis of the user identity, access may be granted or 
denied, and if it is granted, access privileges appropriate 



to the user, his or her group, and/or his or her role can be 
granted. On the basis of the additional security-relevant 
attributes of the client device (e.g., a personal computer 
or laptop computer), its location, its type, or the like, ac- 
cess privileges may be further restricted to ensure that 
unsecured clients (or clients in locations that are not se- 
cure) can have only limited access to certain services, re- 
sources, and/or remote applications. 
[0062] The system and methodology of the present invention can 
be used, for example, to verify that the client attempting 
to access and use a service is running appropriate security 
software which is enforcing a required client security pol- 
icy. The client security software and/or security policy can 
be identified by checksum, policy distinguished name, au- 
thor/publisher, and/or by key policy characteristics such 
as a "firewall security level" that is in effect on the client 
device. These attributes can then be checked and evalu- 
ated either at the client device or at another device (e.g., 
at a server to which the client is requesting access or a 
separate security evaluation service). Access to resources 
requested by the client may be granted or denied, and/or 
access privileges may be established based on this evalu- 
ation. 



[0063] The solution may also be used to verify a number of other 
attributes of the client device that may be of interest. For 
instance, the system may check to ensure that required 
virus suppression measures are in force on a client device. 
The system may, for example, check to determine that an 
anti-virus policy is in force which includes use of a partic- 
ular anti-virus engine version (e.g., from a particular en- 
gine publisher), a particular data file version, and/or a 
particular data file identified by publication date. 

[0064] There are a number of other examples of attributes that 
may be checked using the system and methodology of the 
present invention. For instance, the system may verify that 
a particular file integrity policy (e.g., TripWire) is in force 
on the client. Additional system check rules may include 
verifying that there is a process running on the computer 
with a specific name, or version, or MD5 checksum value. 
As another example, a check may be made for a particular 
file on the client computer that has a specific file path and 
file name, a particular MD5 checksum value, and/or a date 
within (or outside) a specific range. The system may also 
verify whether there is a registry entry on the client com- 
puter with a value that is (or is not) within an allowed set 
of values. These are only some of the examples, and a 



number of other checks may also be made using the 
methodology of the present invention, as desired. 
[0065] The approach of the present invention initially provides 
for user identity to be collected and evaluated according 
to means similar to that of other authentication protocols. 
However, instead of only evaluating user identity before 
permitting access to services or resources, additional at- 
tributes (e.g., security attributes of the client device) are 
also evaluated through a supplemental (or secondary) au- 
thentication process before providing the client with ac- 
cess to particular services and/or resources. These addi- 
tional attributes can be validated in a number of different 
ways, including (but not limited to) using a Secure Socket 
Layer (SSL) certificate exchange, an IPsec certificate ex- 
change, a trust-establishment certificate exchange, or the 
like. Additional attributes can also be validated through 
out-of-band communications via a separate security eval- 
uation service. When provided via a separate security eval- 
uation service, the application server (i.e., the server in 
the client-server scheme) typically consults the separate 
security evaluation service for the result of a separate se- 
curity evaluation that was previously made by the service 
(e.g., an evaluation made at the time of logon confirma- 



tion). 

[0066] | n the presently preferred embodiment, the system and 

methodology of the present invention is utilized for deter- 
mining whether a client may have access to particular ser- 
vices, resources, and/or remote applications. The system 
can also establish the access privileges that are provided 
to the client based on characteristics of the client (e.g., 
the security enforcement attributes presented by the 
client). A security policy (or access policy) is maintained 
based on the characteristics or attributes (e.g., security 
enforcement attributes) that are required or desired as a 
condition for accessing an application or service (or cer- 
tain of its features, resources, or privileges). The access 
policy may, for instance, specify that clients which have 
specific security enforcement attributes will be given par- 
ticular access privileges. The system of the present inven- 
tion makes a decision about the access privileges to be 
provided to a client, based on whether the client's at- 
tributes (e.g., security enforcement attributes) match the 
required attributes specified by the security policy (access 
policy). Security enforcement attributes are only one ex- 
ample of attributes that can be evaluated using the sys- 
tem and methodology of the present invention. A number 



of other attributes and/or conditions may also be evalu- 
ated as previously described. 

[0067] Alternatively, the system may consult with a third party 

authentication, authorization, and accounting ("AAA") ser- 
vice to determine the level of access allowed the client. In 
this event, the AAA service typically returns a list of privi- 
leges or group memberships that describe the appropriate 
privileges the client should be granted. For example, a file 
server normally deals with the following privileges: "read", 
"write", "execute", "create", and "delete". In a network sys- 
tem where there are defined permission groups such as 
"Administrators", "Users", and "Guests", there typically is a 
file server that grants users in the "Administrators" group 
all rights, grants "Users" the rights to "read", "write", and 
"execute" and grants "Guests" only "read" privileges. 

[0068] | n one embodiment in which a client device (e.g., personal 
computer) is connecting to the file server (and establish- 
ing a remote file access session), the system first deter- 
mines the user's identity using traditional authentication 
technology. Next, the system queries the security at- 
tributes of the client, and checks if those attributes are 
acceptable according to the access policy (security policy); 
this can happen by either consulting a cached policy or 



querying a remote policy server. A cached policy is a pol- 
icy stored (e.g., stored on the client device or on the 
server), which has been sent through some other means 
(e.g., sent to the client by a policy server). For example, 
the client (or the server) may have previously downloaded 
a policy file from a policy server via HTTP. 
[0069] Querying a remote policy server (or other security evalua- 
tion service) for determining whether a client is in compli- 
ance with a security policy generally involves the following 
steps. First, the client connects to and sends the current 
list of security attributes to the policy server, which is 
packaged in a suitably formatted query message that also 
includes the user's identity. Next, the policy server uses 
the user's identity, IP address, connection location, and/or 
other parameters, to determine which access policy 
(security policy) should be used to evaluate the user's de- 
vice (i.e., the client device). These policies usually would 
have previously been configured and assigned by the sys- 
tem's administrator. The policy server then examines the 
list of security attributes that it received from the client, 
and checks those attributes using the rules described in 
the access policy. The result of the policy server's exami- 
nation is returned to the client (and/or to one or more 



server(s) or resources to which the client is requesting ac- 
cess) in a message that indicates the client is "compliant" 
or "non-compliant". Although the above discussion pro- 
vides for the evaluation to be performed at the policy 
server, those skilled in the art will appreciate that the 
evaluation may alternatively be performed (in whole or in 
part) at the client device. In this case, the policy server 
provides a list of the required attributes to the client de- 
vice and the client device returns the results of the evalu- 
ation to the server. 
[0070] These operations may be illustrated by an example of a 
user named "Alice" that is normally granted all privileges 
(i.e., "read", "write", "execute", "create", and "delete" privi- 
leges) on a file named "Alice's Important Document.doc" 
that is stored on her file server "\\ALICESERVER" at her of- 
fice. When Alice logs onto her desktop PC ("ALICEWORK") 
in her office, the system determines that ALICEWORK is 
properly protected by a personal firewall and anti-virus 
system. Therefore, when Alice opens a file-sharing ses- 
sion from her PC ALICEWORK to her file server ALICE- 
SERVER, the file-sharing session grants her full privileges. 
However, when Alice connects to the server from her 
home computer ALICEHOME, the system determines that 



her home PC is not running a personal firewall or anti- 
virus system, and is therefore not compliant with the re- 
quired security policy. Therefore, her access privileges are 
reduced — either rejecting her file-sharing session or 
granting her only "read" privileges. 
System components 

[0071] pig. 3 is a block diagram of an environment 300 in which 
the present invention may be embodied. As shown, envi- 
ronment 300 includes a client device (PC) 310, an applica- 
tion server 320, and an authentication server 330 which 
are connected to each other via a network 340. As also 
shown, components of the present invention are installed 
on the client device 310 and on the authentication server 
330. As shown at Fig. 3, a client security module 355 of 
the present invention is installed on the client device 310 
and a sub-authentication filter module 351 and security 
checker 359 are installed on the authentication server 
330. 

[0072] The client device 310 may be a standard personal com- 
puter, such as the above-described system 100. Alterna- 
tively, the client 310 may be a laptop computer, notebook 
computer, personal digital assistant (PDA), or "smart" 
phone. The client security module 355 is installed and 



running on the client device 310. The client device 310 is 
connected via the network 340 to the application server 
320. The application server 320 may be any type of appli- 
cation server that accepts tickets (or other instructions) 
from the authentication server 330 in order to authorize 
performance of certain transactions or interactions. For 
example, the application server 320 may accept Kerberos 
tickets from a Kerberos authentication server. 
[0073] it should be noted that for purposes of the following dis- 
cussion the client 310 may connect to the network 340 
using either a wireline or wireless connection. For exam- 
ple, a client may use a wireline connection (e.g., dial-up, 
ISDN, DSL, cable modem, Tl, or the like) to connect to a 
network. The system and methodology of the present in- 
vention may also be used for clients connecting to a net- 
work through a wireless access point. Connecting to a 
network through a wireless access point that implements 
IEEE (Institute of Electrical and Electronics Engineers) 
802. lx closely resembles the process of logging in to a 
network via a wireline connection. Accordingly, those 
skilled in the art will appreciate that the methodology of 
the present invention is not limited to wireline access to a 
network, but may also be advantageously employed in 



other environments, including wireless environments. In 
addition, although the above discussion refers to a client 
device connecting to a network, devices which may con- 
nect to a network for gaining access to other services may 
include servers as well as client devices. 
[0074] | n one embodiment, the authentication server 330 is a 
Kerberos server for handling user authentication. How- 
ever, the present invention may be used with other au- 
thentication mechanisms, including, for example, the 
Generic Security Service API (GSS-API), the Extensible Au- 
thentication Protocol (EAP), and/or the RADIUS protocol. 
For example, when the client device 310 connects to the 
application server 320, the authentication server 330 is 
invoked to authenticate the user. In accordance with the 
methodology of the present invention, when the authenti- 
cation sever 330 authenticates the identity of the user 
(i.e., the user of client device 310), it then invokes the 
sub-authentication filter module 351. The sub- 
authentication filter module 351, in turn, invokes the se- 
curity checker module 359. The security checker module 
359 uses a "client monitoring protocol" (or "CMP") to 
check if the client device 310 is in compliance with a re- 
quired access policy (security policy). Access by the client 



device 310 to the application server 320 may be regulated 
based upon compliance with the security policy as here- 
inafter described. 
[0075] it should be noted that the above is only one example of 
an environment in which the system and methodology of 
the present invention may be successfully employed. In 
particular, a Kerberos server is used as an example for 
discussion purposes and is not required for implementa- 
tion of the present invention. The present invention may 
be used with a variety of authentication mechanisms, in- 
cluding, for example, GSS-API, EAP (the Extensible Au- 
thentication Protocol), and/or the RADIUS protocol. As will 
be described below, the system and methodology of the 
present invention may be implemented in a number of 
different environments. For example, the methodology of 
the present invention may be implemented using sub- 
authentication filters in a Windows environment, through 
the use of Pluggable Authentication Modules in a Solaris/ 
Linux environment, as well as through Kerberos authenti- 
cation. The operations of the present invention in several 
different environments will now be described in more de- 
tail. 

Sub-authentication Filters in Windows 



[0076] Components of typical Windows sub-authentication filter imple- 
mentation 

[0077] pig. 4 is a block diagram illustrating in more detail an en- 
vironment 400 in which the present invention is imple- 
mented using sub-authentication filters in a Windows en- 
vironment. In the Windows operating system, a dynamic 
link library (DLL) referred to as a "sub-authentication 
module" can be implemented to filter logon requests from 
client devices. The sub-authentication module can deter- 
mine which client device is requesting authentication, and 
then apply additional rules to determine if the client is al- 
lowed to access the services. The DLL can also modify se- 
curity account manager (SAM) database entries to alter the 
security privileges of the client device. 

[0078] As shown at Fig. 4, a typical Windows implementation in- 
cludes many of the same components previously de- 
scribed and illustrated at Fig. 3. These components in- 
clude a client device 310, a client security module 
(TrueVector engine) 355, an application server 320, a 
sub-authentication filter module (sub-authentication DLL) 
351, a security checker 359, and an Ethernet network 340 
to allow the software modules and other components to 
communicate with each other. In a typical Windows instal- 



lation, an Active Directory Server (ADS) 460 serves as the 
authentication server and uses Kerberos authentication 
services 470 for authentication of clients (e.g., client de- 
vice 310) connecting to the application server (e.g., appli- 
cation server 320). A policy server 480 is provided for 
storing a security policy (access policy) which is required 
to be implemented as a condition for accessing the appli- 
cation server 320. As also shown at Fig. 4, an operating 
system and client applications 415 are installed on the 
client device 310. The operation of these components will 
now be described. 
[0079] pigs. 5A-B comprise a single flowchart 500 illustrating the 
operation of the present invention in authenticating a 
client attempting to access an application or service (e.g., 
on an application server). The following description 
presents method steps that may be implemented using 
computer-executable instructions, for directing operation 
of a device under processor control. The computer-exe- 
cutable instructions may be stored on a computer-read- 
able medium, such as CD, DVD, flash memory, or the like. 
The computer-executable instructions may also be stored 
as a set of downloadable computer-executable instruc- 
tions, for example, for downloading and installation from 



an Internet location (e.g., Web server). 

[0080] As shown, the process begins at step 501 when a client 
device (e.g., client device 310) attempts to connect to a 
service (e.g., a service provided on the application server 
320 as shown at Fig. 4). In order to connect to the appli- 
cation server 320, the client must first connect the client 
device 310 to the network 340 (e.g., by powering on the 
client device 310 if a connection has already been config- 
ured). By connecting to the network, the client 310 is now 
able to send communication packets to the application 
server 320 and the Active Directory Server (ADS) 460. 

[0081] when the client device 310 attempts to access the appli- 
cation server 320, at step 502 the client is first required to 
log on to the network by authenticating against the ADS 
460. At step 503, the client 310 and the ADS 460 
(including the Kerberos services 470) each perform the 
steps required by the appropriate authentication protocol 
(e.g., Kerberos) for normal user identity (e.g., user name 
and password) authentication of the client. This includes 
passing authentication messages back and forth between 
the client and the ADS 460 for normal authentication of 
the client device 310. The exact content and number of 
these messages depends upon the authentication method 



configured for the system (e.g., by the system administra- 
tor). In a Windows environment, the method of authenti- 
cation is frequently implemented in a module called a "Se- 
curity Service Provider (SSP)". Further description of Ker- 
beros authentication is provided in "RFC 1510 - The Ker- 
beros Network Authentication Service (V5)", available from 
the Internet Engineering Task Force (IETF), the disclosure 
of which is hereby incorporated by reference. A copy of 
RFC 1510 is available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfcl510.txt). Also see e.g., "RFC 1964 - 
The Kerberos Version 5 GSS-API Mechanism", available 
from the IETF, the disclosure of which is hereby incorpo- 
rated by reference. A copy of RFC 1964 is available via the 
Internet (e.g., currently at www.ietf.org/rfc/rfcl964.txt). 
[0082] Authentication message sequence 

[0083] one example of an authentication message sequence is a 
simple Kerberos user name/password challenge-response 
protocol, which follows the following sequence: 

[0084] i. The client device (e.g., PC) 310 sends packet to the ADS 
460 containing the user name and requesting authentica- 
tion. 

[0085] 2. The ADS 460 sends packet to the client device 310 

challenging the password and containing a challenge key 



which is a sequence of random characters. 
[0086] 3, The client device 310 retrieves the password from the 
end user. 

[0087] 4_ The client device 310 concatenates the random charac- 
ters to the end-user's password, places the resulting 
string into a buffer, and then generates a one-way hash 
value of the buffer contents (e.g., using an MD5 algo- 
rithm). 

[0088] 5, The client device 310 sends the MD5 hash value to the 
ADS 460 in a packet to request authentication. 

[0089] 6. The ADS 460 also computes the same MD5 hash value 
using the password it has stored in its database together 
with the challenge sequence. 

[0090] 7. The ADS 460 compares the two hash values. If they 

match, the ADS 460 has authenticated the user. If they do 
not match, the ADS 460 rejects the authentication of the 
client device 310. 

[009 1 ] Kerberos service invokes sub-authentication filter 

[0092] |f t he ADS 460, using its configured Security Service 

Provider (e.g., Kerberos services 470), manages to au- 
thenticate the user, then at step 504 the Kerberos services 
470 calls a sub-authentication filter module 351 regis- 
tered in the system registry. The sub-authentication filter 



module 351 is intended to allow customization of the lo- 
gon approval process without having to change the Secu- 
rity Service Provider (e.g., Kerberos service) itself; as SSPs 
are complex pieces of software, whereas a sub- 
authentication filter is much simpler to implement. 

[0093] | n the presently preferred embodiment in a Windows envi- 
ronment, the sub-authentication filter module 351 imple- 
ments a "Msvl.OSubAuthenticationFilter" function 
(described below), which can return a value to indicate 
that the user should be logged on, or can return a value to 
indicate the user should not be logged on to the system. 
The filter function can also return a variety of other con- 
nection attributes including security group membership 
and Kerberos ticket validity lifetime. In the presently pre- 
ferred embodiment of the system, a primary function of 
the sub-authentication filter module 351 is to check 
whether the user (e.g., the client device 310 in this exam- 
ple) is in compliance with a required security policy. To 
perform this check, the sub-authentication filter module 
351 invokes the security checker module 359 as will now 
be described. 

[0094] Security challenge to client 

[0095] After the security checker 359 is invoked by the sub- 



authentication filter module 351, at step 505 the security 
checker issues a challenge to the client security module 
355 on the client device 310. More particularly, the secu- 
rity checker 359 challenges the TrueVector engine of the 
client security module 355 using a "client monitoring pro- 
tocol" or "CMP" challenge message. In response, at step 
506 the TrueVector engine of the client security module 
355 consults the policy server 480 for obtaining the cur- 
rent security policy and compares the current security 
policy to the cached policy stored locally on the client de- 
vice 310. As part of this process, the client security mod- 
ule 355 on the client device 310 determines whether the 
client is in compliance with this updated (i.e., current) se- 
curity policy. The TrueVector engine of the client security 
module 355 then returns the result of this compliance 
check to the security checker 359. 

[0096] | n an alternative embodiment, the policy server 480 may 
perform the security check. The process for the policy 
server 480 checking whether a client is in compliance with 
a required security policy generally involves the perfor- 
mance of the following steps: 

[0097] i The client security module 355 on the client device 310 
connects to and sends the current list of security at- 



tributes to the policy server 480. The list of security at- 
tributes is packaged in a suitably formatted query mes- 
sage that also includes the user's identity. 

[0098] 2. The policy server 480 uses the user's identity, IP ad- 
dress, connection location, and/or other parameters to 
determine which security policy should be used to evalu- 
ate the user and the client device 310. These policies 
would have previously been configured and assigned by 
the system's administrator. 

[0099] 3. The policy server 480 examines the list of security at- 
tributes that it received from the client device 310, and 
checks those attributes using the rules described in the 
security policy. 

[0100] 4. jhe result of the examination process by the policy 

server 480 is returned to the client device 310 in a mes- 
sage that indicates "compliant" or "non-compliant". The 
client may then return the result of this compliance check 
to the security checker 359. Alternatively (or in addition), 
the policy server 480 may return the result directly to the 
security checker 359. 

[0101] Grant of privileges to the client based on security check 

[0102] | n t he presently preferred embodiment, the security 
checker 359, in turn, returns a value (e.g., numerical 



value) at step 507 to indicate the status of the client that 
was checked (e.g., the client device 310). For example, if 
the value returned number is equal to 0, then the client is 
accepted as secure and the sub-authentication filter mod- 
ule 351 will typically authorize the user (e.g., client device 
310) to access the application server 320 at step 508 by 
returning " STATU S.SUCC ESS" as a return code. If the secu- 
rity checker 359 returns a non-zero value (e.g., a value of 
1 or greater) to the sub-authentication filter module 351, 
then the client is not accepted as secure and at step 509 
the sub-authentication filter module 359 will deny autho- 
rization to access the application server 320 by returning 
an error code. 

[0103] Alternatively, if the client is not accepted as secure the 
sub-authentication module 359 may authorize the user 
(e.g., client 310) to access the application server, but alter 
the user's access group membership by altering the user's 
group membership in a "UserAII->SecurityDescriptor" 
data structure that was passed into the sub- 
authentication filter module 351. This data structure is a 
self-referential security descriptor that describes the se- 
curity privileges of an account. Changing this data struc- 
ture alters the contents of a SAM (security account man- 



ager) database when the sub-authentication filter module 
351 returns the result of the security check. In one em- 
bodiment of the system, the group membership of the 
user is changed to grant only limited group membership 
when the user (client) is not in compliance with the cur- 
rent security policy. In this manner, the user can be 
granted access to the network using "Guest" group privi- 
leges only. In this event, the computers in the domain can 
be configured to allow members of the "Guest" group 
read-only access to their services, for instance. This 
group membership privilege is typically encoded into a 
Kerberos ticket issued by a Kerberos key distribution cen- 
ter (KDC) component of the Kerberos services 470. 
[01 04] ^5 issues a Kerberos ticket to the client 

[0105] Upon successful authentication, the Kerberos services 470 
of the ADS 460 will authorize the client to access the ap- 
plication server 320. Typically, the Kerberos KDC service 
will grant the client 310 a Kerberos ticket that will allow 
the client to connect and authenticate against the applica- 
tion server 320 (and/or other application servers in the 
domain). The ticket generally contains, among other 
things, an "AuthorizationData" field that contains, in a Mi- 
crosoft ADS implementation, a "SecurityDescriptor" data 



structure. This "SecurityDescriptor" data structure de- 
scribes, among other things, the group memberships the 
user of the client device is assigned. 

[01 06] Authorizing a transaction by checking the Kerberos ticket 

[0107] when the client device attempts to perform a transaction 
with any Kerberos-compatible application server in the 
network, the application server will request from the client 
proof that it has permission to perform the transaction, in 
the form of the Kerberos ticket that was issued to the 
client. If the client has been successful in authenticating 
with the ADS server, then it will have been issued a Ker- 
beros ticket that the application server can use to autho- 
rize the transaction. However, if the client has been issued 
a Kerberos ticket that contains only "Guest" group mem- 
bership privileges, then the application server might deny 
access to the client, or it may authorize only limited privi- 
leges for the transaction. 

[0108] The precise set of privileges granted to members of each 
ADS group can vary depending on various factors, includ- 
ing the kind of application server that is involved. For ex- 
ample, if the application server is a file server, the user 
rights granted to a "Guest" user may be limited to "read 
only access to the Guest share folder; no access to any 



other folder". Those skilled in the art will appreciate that 
various other privileges may be configured and assigned 
to clients using the methodology of the present invention. 

[0 1 09] Operations with Kerberos 

[0110] pigs. 6A-B comprise a single flowchart 600 illustrating the 
operations of the present invention in authenticating a 
client accessing a service in a Kerberos implementation. 
As with the prior flowchart, the following description 
presents method steps that may be implemented using 
computer-executable instructions, for directing operation 
of a device under processor control. The computer-exe- 
cutable instructions may be stored on a computer-read- 
able medium, such as CD, DVD, flash memory, or the like. 
The computer-executable instructions may also be stored 
as a set of downloadable computer-executable instruc- 
tions, for example, for downloading and installation from 
an Internet location (e.g., Web server). 
The process begins at step 601 with a client (e.g., a per- 
sonal computer) connecting to a network to attempt to 
gain access to a service available on the network. At step 
602 the client receives the network address of an authen- 
tication server. Next, at step 603 the client logs in to the 
authentication server and provides required credentials 



(e.g., user name and password or other credentials). The 
client and the authentication server perform the steps re- 
quired for normal user identity (e.g., user name and pass- 
word) authentication of the client. 

[0112] After the user is initially authenticated (e.g., based on user 
name and password), at step 604 the authentication 
server calls a sub-authentication filter module. At step 
605, the sub-authentication filter module invokes a secu- 
rity checker module. The security checker module issues a 
security challenge. As previously described, the security 
challenge may be issued directly to the client or by re- 
questing results of a security evaluation previously per- 
formed by a policy server or other security evaluation ser- 
vice. Next, at step 606 a determination is made as to 
whether the client is in compliance with the security policy 
required for access. In the presently preferred embodi- 
ment, this determination is made at the client in most 
cases; however, the determination may also be made by 
the server issuing the challenge or by a separate security 
evaluation service (e.g., policy server or the like). The re- 
sult of the compliance check is returned at step 607. 

[0113] if the client is in compliance with the security policy, at 

step 608 the client is granted a Kerberos ticket containing 



appropriate access privileges (e.g., full access privileges). 
However, if the client is not in compliance with the policy, 
at step 609 the authentication of the client fails or the 
client is granted a limited access Kerberos ticket (i.e., lim- 
ited privileges, such as read-only access or access to only 
certain resources). 
[° 114 ] At step 610 the client subsequently connects to a service 
available on the network and requests a transaction. In re- 
sponse, at step 611 the service requires the client to 
present its Kerberos ticket. At step 612 the client presents 
the Kerberos ticket to the service in response to the re- 
quest. At step 613 the service checks the ticket to deter- 
mine if it contains sufficient privilege to permit the re- 
quested transaction. If the ticket contains sufficient privi- 
lege to permit the transaction, at step 614 the service ex- 
ecutes the transaction. However, if the Kerberos ticket 
does not contain sufficient privilege, or if no ticket was is- 
sued to the client, at step 615 the service denies the 
transaction requested by the client. 
Kerberos implementation 

[0115] a pure Kerberos implementation may be constructed to 
perform the same authentication process described 
above. However, unlike the case of the above-described 



Microsoft Windows ADS implementation, no sub- 
authentication filter module is required for a pure Ker- 
beros implementation. Those skilled in the art will appre- 
ciate similar functionality can be built into the readily 
available open-source Kerberos implementations (e.g., 
MIT Athena, MAC OSX) instead of implementing such 
functionality in separate sub-authentication modules. 
[0116] The steps listed above for the Microsoft sub- 
authentication operation describe the operational steps 
that are applicable in the case of a general Kerberos im- 
plementation. However, the sub-authentication module is 
replaced with built-in code in the Kerberos implementa- 
tion which accomplishes the same task as an external 
sub-authentication filter module (including the functions 
of the security checker module). 
Pluggable Authentication Modules 

[° 117 ] Fig. 7 is a block diagram illustrating an environment 700 
in which the methodology of the present invention may be 
implemented in a Linux, UNIX, or Solaris environment us- 
ing Pluggable Authentication Modules. Pluggable Authen- 
tication Modules (or "PAM modules") allow multiple au- 
thentication mechanisms to be used collectively or inde- 
pendently. As shown, the environment 700 includes a 



client device 710 connected to a system 720 and a policy 
server 780 via a network 740. The system 720 may be 
running a Linux, UNIX, or Solaris operating system and in- 
cludes an application server 730, a PAM library 750, a 
PAM configuration file 755, a PAM (standard authentica- 
tion) module 760, a PAM_TV module 765, and a security 
checker 770. Although these modules are shown as being 
installed together on a single machine, they may also be 
installed on different machines, as desired. The client de- 
vice 710 includes an operating system/client applications 
713 and the client security module (TrueVector engine) 
715 as previously described. The operations of these 
components in authentication of a user will now be de- 
scribed. 

18 ] Initially, the Pluggable Authentication Modules are config- 
ured to require an additional authentication method for 
each protected service on the system 720. An additional 
PAM module(s) is added for authentication of a user 
(client) on a designated (named) service (e.g., a service 
provided by the application server 730). It should be 
noted that the PAM module(s) which is added for purposes 
of implementing the methodology of the present inven- 
tion is typically an additional module that works in con- 



junction with another module that performs the primary 
authentication based on user identity. As shown at Fig. 7, 
the PAM_TV module 765 implements the methodology of 
the present invention for supplemental authentication of 
the user. This PAM_TV module 765 is typically used in 
conjunction with a standard PAM module 760 which au- 
thenticates a client in a standard fashion based upon user 
identity (e.g., user name and password). In this case, both 
of the PAM modules used for user authentication (e.g., 
PAM module 760 and PAM_TV module 765) are listed in 
the PAM configuration file 755 in the appropriate order. 
Those skilled in the art will appreciate, however, that a 
single module providing for both authentication of user 
identity and supplemental authentication of other at- 
tributes could be used instead of multiple modules, if de- 
sired. 

1Q ] When a client (e.g., client device 710) attempts to connect 
to the application server 730, the required PAM modules 
are invoked by the application server 730 (via the PAM li- 
brary 750) to authenticate the user (e.g., based on user 
identity) as well as to authenticate (or authorize) the client 
device for access based upon supplemental attributes of 
the user and/or the client device. A 



"pam_sm_authenticate" function or a 
"pam_sm_open_session" function is called, as appropriate, 
to approve the authentication of the client or a new appli- 
cation server session for the client (e.g., the client device 
710). 

[0120] when the PAM_TV module 765 implementing the method- 
ology of the present invention is invoked, it calls the client 
security checker 770 (described below) to perform the 
check on the client computer's security. This security 
check may be performed directly or indirectly. For in- 
stance, the security check can be performed by issuing a 
challenge to the client and evaluating the response in a 
manner similar to that described above for the Windows 
sub-authentication filter implementation. Alternatively, a 
separate security evaluation service (e.g., a policy server) 
may be consulted for the result of a prior security evalua- 
tion. Based on the examination of the attributes of the 
client device 710, the security checker 770 typically re- 
turns a value of zero (0) to indicate that the client is se- 
cure, or a value of one (1) or above to indicate that the 
client is not secure. If the client security checker 770 re- 
turns a zero value, indicating that the client is secure (i.e., 
in compliance with the required security policy), the 



PAM.TV module 765 returns "PAM .SUCCESS" to allow the 
authentication to succeed. However, if the security 
checker 770 returns a non-zero value, the PAM_TV mod- 
ule 765 returns " PAM_AUTH_ERR" to prevent the authenti- 
cation of the client from succeeding. For example, if the 
PAM library 750 returns "PAM.SUCCESS" to the application 
server 730, the application server 730 grants access to 
the client device 710; otherwise, it denies access. 
[° 121 ] It should be noted that instead of simply blocking or 

granting access to the client device, a client found not to 
be in compliance may permitted to access the application 
server 730, but with reduced privileges. For instance, the 
user may be permitted to access the application server, 
but provided with read-only access. Those skilled in the 
art will appreciate that various other privileges may be 
configured and assigned to clients based on the results of 
the compliance evaluation. One embodiment of the 
present invention implemented using sub-authentication 
filters in a Windows environment will next be described in 
greater detail. 
Detailed Internal Operation 

[° 1 22 ] Sub-authentication filters in a Windows environment 



[0123] As described above, in the Windows operating system, a 
DLL called a "sub-authentication module" can be imple- 
mented to filter log on requests from client devices (e.g., 
client PCs). The module can determine which client is re- 
questing authentication, and then apply additional rules to 
determine if the client is allowed to access particular ser- 
vices (e.g., determining if the client is in compliance with 
a security policy). The DLL can also modify security ac- 
count manager (SAM) database entries to alter the security 
privileges of the client device. Additional information re- 
garding implementation of a sub-authentication filter 
module in Windows is available from Microsoft Corpora- 
tion and is available via the Internet (e.g., currently at 
msdn.microsoft.com/library/en-us/security/security/msv 
l.Osubauthenticationroutine.asp). 

[0124] | n the following example, a 

"Msvl.OSubAuthenticationFilter" function is implemented 
and exported from a DLL: 

[0125] i: NTSTATUS 
2: NTAPI 

3: Msvl.OSubAuthenticationFilter ( 

4: IN NETLOGON_LOGON_INFO_CLASS LogonLevel, 

5: IN PVOID Logonlnformation, 



6: IN ULONG Flags, 

7: IN PUSER_ALL_INFORMATION UserAII, 

8: OUT PULONG WhichFields, 

9: OUT PULONG UserFlags, 

10: OUT PBOOLEAN Authoritative, 

11: OUT PLARGEJNTEGER LogoffTime, 

12: OUT PLARGEJNTEGER KickoffTime 

13: ); 

[0126] The above "Msvl_OSubAuthenticationFilter" function is 

registered as an "AuthO" handler, which is the general au- 
thentication filter for a Windows machine or a Domain 
Controller. The authentication filter function returns "STA- 
TUS.SUCCESS" if the authentication is approved, or an er- 
ror code if the authentication is not approved. The "Logo- 
nlnformation" field at line 5 above is a pointer to a "NETL- 
OGON_LOGON_IDENTITY_INFO" data structure, which in- 
cludes information about the client logging on, including 
the user name, authenticating domain, and the client 
workstation or device. 

[0127] The following sub-authentication filter module invokes a 
security checker routine which is responsible for sending 
a challenge packet to a client workstation (device) for au- 
thentication of the client device: 



[0128] i; Msvl.OSubAuthenticationFilter ( 

2: IN NETLOGON_LOGONJNFO_CLASS LogonLevel, 
3: IN PVOID Logonlnformation, 
4: IN ULONG Flags, 

5: IN PUSER_ALL_INFORMATION UserAII, 

6: OUT PULONG WhichFields, 

7: OUT PULONG UserFlags, 

8: OUT PBOOLEAN Authoritative, 

9: OUT PLARGEJNTEGER LogoffTime, 

10: OUT PLARGEJNTEGER KickoffTime 

11: ) 

12: { 

13: NTSTATUS Status; 

14: SYSTEMTIME CurrentTime; 

15: PNETLOGON.LOGONJDENTITYJNFO Identity = 

16: (PNETLOGON_LOGON_IDENTITY_INFO)Logonlnforma 

tion; 

17: WCHAR wszComputerName[MAX_COMPUTERNAME_LE 
NGTH + 1]; 

18: DWORD cbSize = MAX.COM PUTERNAME.LENGTH + 1; 
19: 

20: Status = STATUS.SUCCESS; 
21: 



22: *Authoritative = TRUE; 
23: *UserFlags = 0; 
24: *WhichFields = 0; 
25: 
26: 

27: GetLocalTime( &CurrentTime ); 

28: 

29: if (Mdentity) 
30: { 

31: logprintf("No identity\r\n"); 

32: return Status; 

33: } 

34: 

35: 

36: logprintf( 

37: "%02d/%02d/%d %02d:%02d:%02d: Logon (level=%d 
) %wZ\\%wZ (%wZ) 
from %wZ\r\n", 

38: CurrentTime.wMonth, CurrentTime.wDay, CurrentTi 
me.wYear, 

39: CurrentTime.wHour, CurrentTime.wMinute, Current 

Time.wSecond, 

40: LogonLevel, 



41: &ldentity->LogonDomainName, &ldentity->UserNa 
me, 

42: &UserAII->FullName, &ldentity->Workstation); 

43: 

44: 

45: switch ( LogonLevel ) 

46: { 

47: case Netlogonlnteractivelnformation: 

48: case NetlogonServicelnformation: 

49: case NetlogonNetworklnformation: 

50: GetComputerNameW( wszComputerName, &cbSize ) 

51: 

52: // If client is remote 

53: if (ldentity->Workstation. Buffer != NULL && 

54: wcsncmp(ldentity->Workstation. Buffer, wszComp 

uterName, 

ldentity->Workstation. Length ) != 0) 

55: { 

56: // check the client using the checkclient utility 
57: 

58: if (_wspawnl (_P_WAIT, L"checkclient.exe", 
59: ldentity->Workstation. Buffer) != 0) 



60: { 

61: Status = ERRORJNVALID.WORKSTATION; 

62: I ogprintf(" Invalid foreign workstation login from: 

%wZ\n", 

&ldentity->Workstation ); 

63: } 
64: 

65: } 

66: LARGE. INTEGER CurrentUTCTime; 

67: QuerySystemTime( &CurrentUTCTime ); 

68: 

69: if (LogoffTime) 
70: { 

71: // this sets the ticket lifetime to HeartbeatRate 
(30 minutes default) 

72: LogoffTime->QuadPart = CurrentUTCTime. QuadP 
art + 

(HeartbeatRate * 10000000); 

73: } 

74: 

75: if (KickoffTime){ 

76: KickoffTime->HighPart = 0x7FFFFFFF; 
77: KickoffTime->LowPart = OxFFFFFFFF; 



78: } 

79: break; 
80: 

81: default: 

82: return STATU S_ INVALID. I NFO.C LASS; 

83: } 

84: 

85: return Status; 
86: } 

[0129] As shown at lines 58-59, the sub-authentication filter 

module invokes a security checker routine named "check- 
client. exe". This security checker, when invoked, issues a 
challenge packet requesting the client to confirm its secu- 
rity attributes. The security checker then verifies the iden- 
tity of the client and determines if the attributes of the 
client device are appropriate according to the required se- 
curity policy. If the attributes are not appropriate (e.g., the 
client is not in compliance with a required security policy) 
then the security checker routine returns an error from 
the filter function. 

[01 30] implementation in a Kerberos system 

[° 131 ] In a network environment with many service applications 
distributed on different network nodes, a Kerberos-based 



authentication/authorization system is often used. In a 
Kerberos implementation, the authentication system is 
separated from the service requesting the authentication. 
When the client wishes to utilize a service application, the 
client logs on to a Kerberos "key distribution center" (or 
"KDC" server). For standard user identity authentication, if 
the client can be authenticated using a normal authentica- 
tion protocol (e.g., user name/password), the client is 
given a "ticket". This ticket is then presented to the ser- 
vice when the client connects to the application service, 
through an "Internet Key Exchange" (or "IKE") protocol. 
The ticket contains data indicating what types of services 
it can provide access to, and it also contains an expiration 
date. Most importantly, the ticket also contains crypto- 
graphic information used to validate the integrity and va- 
lidity of the ticket itself; this allows the application service 
to safely grant access to a ticket-holding client without 
having to check back with the Kerberos authentication 
server. 

[0132] jo implement the security checking mechanism of the 
present invention in a Kerberos environment simply re- 
quires that the client security checking be done as part of 
the KDC interaction/authentication process as described 



above. The client security checking is performed against 
the KDC server instead of exchanging the client security 
information with the application server. If the client com- 
puter is not in compliance with the required security pol- 
icy, the KDC server can either reject the client (i.e., not is- 
sue a ticket to the client), or it can grant the client a ticket 
with more limited access privileges than would normally 
be granted to an end user that is in compliance with the 
security policy. 

[0133] | n a network using a Microsoft Active Directory Server 

(ADS) for authentication, it is possible to implement this 
same type of behavior. This same type of behavior may be 
established by implementing and registering a 
"Msvl.OSubAuthenticationFilter" function on all Domain 
Controllers (containing Kerberos KDCs) in the network. 

[01 34] pluggable Authentication Modules in Unix/ Solaris /Linux 

[0135] in the Unix family of operating systems (including Solaris 
and Linux), Pluggable Authentication Modules (PAM mod- 
ules) can be used to assign specific authentication meth- 
ods to specific services. With the Pluggable Authentication 
Module (PAM) framework, multiple authentication tech- 
nologies can be added without changing any of the login 
services, thereby preserving existing system environ- 



merits. PAM modules can be used to integrate login ser- 
vices with different authentication technologies, such as 
RSA, DCE, Kerberos, S/Key, and smart card based authen- 
tication systems. Thus, Pluggable Authentication Modules 
enable networked machines to exist peacefully in a het- 
erogeneous environment, where multiple security mecha- 
nisms are in place. 

[0136] The following example illustrates the signature of a 

"pam_sm_authenticate" method which is implemented and 
exported from a loadable library called "pam.coop.so": 

[0 1 3 7 ] 1: PAM.EXTERN int 

2: pam_sm_authenticate (pam_handle_t * pamh, 
3: int flags, int argc, const char **argv) 

[0138] The PAM module is registered in a PAM configuration file 
and is associated with one or more services running on 
the server computer. The following is an example PAM 
configuration file named "/etc/pam.d/ftpd", which config- 
ures a number of authentication settings for an FTP (file 
transfer protocol) daemon: 

[0 1 39] 1: # PAM configuration for ftpd 

2: auth requisite pam_securetty.so 
3: auth required pam_nologin.so 
4: auth required pam_env.so 



5: auth required pam_unix.so nulok 

6: account required pam_unix.so 

7: account required pam_coop.so 

8: session required pam_unix.so 

9: session optional pamjastlog.so 

10: password required pam.unix. so nullok obscure mi 

n=4 max=8 

[0140] Commonly, PAM configuration files are stored in the "/ 
etc/pam.d" directory, and each file is associated with a 
service (e.g., an FTP daemon in this example) that is run- 
ning on the computer. In this example, the file called "lo- 
gin" controls the main user login processing for the sever 
computer. Lines 1-6 and 8-10 above are configuration 
commands which would be commonly found in any PAM- 
compliant installation. Of particular interest, the code at 
line 7 indicates that the PAM system must invoke the 
"pam.coop.so" module in order to allow a user to login 
successfully, and it also indicates that if the "pam.coop.so 
module" denies access, then the user is not permitted to 
log into the computer (i.e., the server). Alternative PAM 
implementations may provide for storing configuration in- 
formation in a single configuration file called "/ 
etc/pam.conf". The information stored in this single con- 



figuration file is otherwise identical to the information 
stored in the "/etc/pam.d" directory. 
[0141] when a client attempts to authenticate to the service, the 
service invokes the PAM subsystem to perform the au- 
thentication using the PAM authentication function 
"pam.authenticate". The PAM subsystem reads (or has 
read) the configuration file associated with the service and 
consults each of the authentication modules listed in the 
configuration file. Since one of the listed authentication 
modules is the module that implements client compliance 
checking, the "pam.coop.so module" will be called during 
the processing of the authentication. In particular, when a 
new session is created on the service for communicating 
with the client, the above "pam_sm_authenticate" method 
is invoked. 

[0142] when the session is requested by a remote computer, 
most services will provide the host name of the remote 
computer making the access request. The following 
"pam_sm_open_session" method can retrieve this host 
name using a "pam_get_item" method as follows: 

[0143] i: rhost_retval = pam_get_item(pamh, PAM.RHOST, (const 
void **)&rhost); 

[0144] when the host address is retrieved, the address is passed 



to a utility to check the host integrity of the accessing 
client (remote host) as follows: 
[0 14 5] 1: if (_spawnl (_P_WAIT, "checkclient.exe", 
2: rhost_retval) != 0) 

3: { 

4: I ogprintf(" Invalid foreign workstation login from: % 
wZ\n", 

&ldentity->Workstation ); 
5: return PAM_AUTH_ERR; 
6: } 
7: else 

8: return PAM.SUCCESS; 

[0146] As shown, a "checkclient.exe" utility is invoked at line 1. 
The "checkclient.exe" utility is a security checker respon- 
sible for communication with the client to check the secu- 
rity attributes of the client. This security checker sends a 
challenge packet to the remote host (i.e., client), request- 
ing the client to confirm its security attributes. The secu- 
rity checker then determines if the attributes are appro- 
priate according to the required security policy, and if 
they are not then the security checker returns an error 
(i.e., "return PAM_AUTH_ERR" as shown at line 5). 

[0147] when the "pam_sm_authenticate" method returns, the 



PAM subsystem remembers the return value, and may 
continue calling the other PAM modules listed in the ser- 
vice's configuration file to confirm the user's authentica- 
tion. When all the necessary modules have been con- 
sulted, the PAM subsystem computes the aggregate result 
of all the modules, as specified in the configuration file. 
The aggregate result will usually be "PAM.SUCCESS" if all 
the required modules returned "PAM.SUCCESS", otherwise 
it will be "PAM_AUTH_ERR" if any one of the required 
modules returned "PAM_AUTH_ERR"._The PAM subsystem 
then returns this result to the service, which accepts or 
rejects the user session based on this final authentication 
result. In the case of the FTP daemon above, the daemon 
can issue an FTP "530 Not logged in" error. 
[01 48] How compliance is requested and communicated 

[0149] | n one embodiment, the security checker (i.e., the above- 
described "checkclient" utility) employs a "client monitor- 
ing protocol" for communication with the client. The client 
monitoring protocol (CMP) is a simple monitoring protocol 
that is used to check the security attributes of the client 
device (e.g., that a particular security solution is installed 
on the client computer and/or that the client is running a 
particular version of the security solution). The CMP may 



also be used to monitor and enforce compliance with any 
additional policies selected by the administrator (e.g., that 
the client is using particular anti-virus software). The CMP 
currently uses the UDP protocol on both the server-side 
and on the client-side. Challenge and response packets 
are encrypted for transmission between the client and the 
server. Each packet generally consists of a header, a body, 
and (optional) additional parameters. This structure en- 
sures expandability and interoperability even if the 
server-side security checker and the client(s) use different 
versions of the protocol. 
[0150] The server-side security checker module sends an initial 
CMP challenge packet to a client device seeking to access 
particular resources as part of the authentication process. 
The CMP challenge packet is a UDP message which is for- 
mulated and sent to the client. In the presently preferred 
embodiment, the challenge packet has a fixed header and 
it has additional parameters that can be selected as op- 
tions in order to check for particular attributes or condi- 
tions at the client device. For example, a "client version" 
option allows the administrator to require that a specific 
minimum version of the security solution be installed on 
the client computer. An "anti-virus challenge" option pro- 



vides for checking for anti-virus enforcement. The secu- 
rity checker module looks for the appropriate code to ver- 
ify if the anti-virus program is running on the client ma- 
chine and if both the anti-virus program and the associ- 
ated data file are up to date. The security checker module 
may also issue periodic "heartbeat" challenges every N 
seconds or minutes, as determined by the monitoring fre- 
quency setting established by the administrator. 
[0151] upon receipt of a challenge packet, the client security 

module of the present invention (which is installed on the 
client device) formulates an appropriate response mes- 
sage using the same CMP protocol. The response message 
describes whether the client is currently compliant with 
the requirements provided in the challenge message. The 
security checker may then communicate the results of the 
security check and/or determine whether, and to what ex- 
tent, the client should be permitted access based on the 
security check. 

[0152] Those skilled in the art will appreciate that there are a 

number of other ways to communicate compliance status 
using other communication mechanisms. For example, 
security compliance may be checked using the EAP proto- 
col which defines a challenge-response protocol between 



an authentication server and a client computer. For further 
information regarding EAP, see e.g., "RFC 2284: PPP Ex- 
tensible Authentication Protocol", available from the Inter- 
net Engineering Task Force (IETF), the disclosure of which 
is hereby incorporated by reference. A copy of RFC 2284 
is available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc2284.txt). As another example, the 
RADIUS protocol, which uses UDP messages to perform a 
challenge/response protocol, may also be used for com- 
pliance checking. For further information regarding RA- 
DIUS, see e.g., "RFC 2865: Remote Authentication Dial In 
User Service (RADIUS)", available from the IETF, the disclo- 
sure of which is hereby incorporated by reference. A copy 
of RFC 2865 is available via the Internet (e.g., currently at 
www.ietf.org/rfc/rfc2865.txt). Alternatively, certificates 
may be exchanged by the client and server via a TLS or 
TNT trust exchange. 
[0153] The above discussion uses an example of how compliance 
status can be requested and communicated by issuing 
challenges to a client and receiving responses from the 
client. As previously discussed, there are a number of dif- 
ferent ways in which security attributes may be communi- 
cated and validated. For instance, an alternative embodi- 



ment of the present invention provides for the additional 
security attributes to be validated through out-of-band 
communications via a separate security evaluation service. 
In this alternative embodiment, if a client has already con- 
nected to the network, the security attributes may have 
been previously evaluated by a separate security evalua- 
tion service (e.g., a policy server or the like). Typically, the 
security evaluation service evaluates security compliance 
at the time of initial authentication of the client. Subse- 
quently, when the client requests a particular service or 
transaction, the results of the prior security evaluation are 
obtained from the security evaluation service rather than 
using the above challenge/response process directly with 
the client. In other words, when the client requested a 
particular service or application, the separate security 
evaluation service would be consulted for the result of a 
prior evaluation. Those skilled in the art will appreciate 
that there are a number of approaches that may be used 
to communicate regarding the compliance status of client 
devices requesting access to services or resources. 
[0154] pigs. 8A-B comprise a single flowchart 800 illustrating the 
process of authenticating a client attempting to access an 
application or service (e.g., on an application server) 



through a separate security evaluation service. As with the 
prior flowcharts, the following description presents 
method steps that may be implemented using computer- 
executable instructions, for directing operation of a device 
under processor control. The computer-executable in- 
structions may be stored on a computer-readable 
medium, such as CD, DVD, flash memory, or the like. The 
computer-executable instructions may also be stored as a 
set of downloadable computer-executable instructions, 
for example, for downloading and installation from an In- 
ternet location (e.g., Web server). 
[0155] At step 801 a client (e.g., a personal computer) connects 
to a network to attempt to gain access to a service avail- 
able on the network. At step 802 the client receives the 
network address of an authentication server. The client 
logs in to the authentication server and provides required 
credentials (e.g., user name and password or other cre- 
dentials) at step 803. If the client is authenticated, a secu- 
rity evaluation service (e.g., policy server) is then invoked 
to determine the client's compliance with a policy required 
for access to services and resources. At step 804 the pol- 
icy server issues a communication (e.g., policy challenge) 
to the client requesting information from the client about 



its state. 

[0156] | n response to the challenge from the policy server, the 
client collects and sends the requested information to the 
policy server at step 805. The information received by the 
policy server may, for example, include the policy MD5 of 
the policy on the client device and/or other relevant infor- 
mation required to determine the client's compliance sta- 
tus. Based on the information received from the client, at 
step 806 the policy server determines whether or not the 
client is in compliance with the required policy. It should 
be noted that the client may alternatively perform the 
evaluation itself and send the results of the compliance 
check to the policy server as previously described. At step 
807, the policy server retains and/or stores the result of 
the compliance evaluation. 

[0157] The client subsequently connects to a service available on 
the network and requests a transaction at step 808. In re- 
sponse, at step 809 the service communicates with the 
policy server (e.g., sends a message to the policy server) 
asking the policy server whether or not the client is in 
compliance with the policy. At step 810 the policy server 
returns the result of the compliance check of the client in- 
dicating whether or not the client is in compliance with 



the policy. If the response (i.e., result of compliance 
check) received from the policy server indicates that the 
client is in compliance, then at step 811 the service allows 
the transaction requested by the client. However, if the 
result returned by the policy server indicates that the 
client is not in compliance with the policy, at step 812 the 
service denies the transaction. 

[0158] As yet another alternative example, the server providing 
the service that is requested by the client can be con- 
structed and configured to check some or all of the policy 
rules that the policy server may otherwise evaluate, 
thereby removing the need to use an external policy 
server for policy enforcement. Those skilled in the art will 
appreciate that a number of other configurations may be 
used for evaluating and enforcing compliance with a pol- 
icy. For example, a particular server may handle certain 
matters while invoking an external policy service in other 
situations, depending on such factors as the complexity of 
the decision-making process and the performance impact 
of consulting an external policy service. 

[0 1 59] h ow compliance is evaluated 

[0160] a basic implementation of the compliance evaluation pro- 
cess will now be briefly described. In the presently pre- 



ferred embodiment, checking the client's system configu- 
ration for compliance with a security policy involves sev- 
eral basic steps. These steps generally follow after the 
user authentication (e.g., user name and password au- 
thentication) has been completed. 

[0161] The server (e.g., the security checker on the server or a 
separate security evaluation service) initially requests a 
client configuration report with specified parameters from 
the client. The list of parameters requested in the report is 
specified by the required security policy. In response, the 
client provides the client security checker on the server a 
client configuration report. The client configuration report 
describes configuration information about the client, in- 
cluding those parameters requested by the server. 

[0162] Next, the security checker evaluates the client configura- 
tion report for compliance against the required policy. 
Generally, the security checker determines whether or not 
the values provided in the client configuration report are 
within the allowed (or required) range. Based on this eval- 
uation, the security checker on the server generates a 
compliance report. The compliance report indicates if 
there are any noteworthy results in the compliance check 
step. These items can either be parameter requirements 



which are not satisfied (and therefore indicate an out- 
of-compliance condition), or they can be parameter re- 
quirements which are within an allowed range, but never- 
theless should be logged for further examination or to 
alert the user or administrator. Finally, a compliance result 
is compiled from the compliance report, which indicates 
either that the client is "compliant" or "out- 
of-compliance". 
[0163] if the client is determined to be "out of compliance" the 
system should take appropriate action to block or restrict 
further client access either to the system, or to certain of 
its services or resources. The above security evaluation 
process may easily be modified to fit circumstances or 
performance requirements, as needed. One option, for in- 
stance, is for the server to push the compliance require- 
ments to the client and have the client compute the com- 
pliance report and compliance status. This frees the server 
from needing to process the compliance report, which 
may reduce CPU processing overhead at the server. Those 
skilled in the art will appreciate that the above evaluation 
process can be performed at either the client or the server 
depending on various factors, including which alternative 
minimizes the amount of data that must be sent back and 



forth and system responsiveness to changes in security 
policies. 

[0164] | n f ac t, j n many cases the compliance evaluation is most 
efficiently performed on the client device, as performing 
the evaluation at the client can offload processing from 
the server and reduce the amount of information that 
must be communicated by the client to the server. For ex- 
ample, the server (or an external policy server) may send a 
policy or a set of required security attributes to the client. 
The client can then evaluate compliance with the policy 
and simply inform the server of the result of the compli- 
ance evaluation. This message informing the server of the 
result can be quite small, thereby preserving bandwidth as 
well as reducing processing overhead at the server. How- 
ever, this structure may require a relatively large policy (or 
set of required security attributes) to be downloaded to, 
or otherwise available at, the client. This is particularly 
true if the security policy that is being enforced has a 
large number of conditions (e.g., required security at- 
tributes). A security policy may, for example, include a 
long list of processes (e.g., with a particular file name or 
checksum) that should not be running on the client de- 
vice. It would be inefficient to send a lengthy list of condi- 



tions of this nature to the client every time that compli- 
ance is to be evaluated. However, given that the security 
policy is often available at the client device (e.g., as it has 
previously been downloaded to the client by a separate 
policy server), the amount of data that must be communi- 
cated to the client is minimal in many cases. Also, because 
the frequency of policy changes is generally low compared 
to the number of times compliance is evaluated, perform- 
ing the evaluation at the client typically results in an over- 
all reduction in the volume of data that must be commu- 
nicated between the client and the server. 
[0165] | n certain cases, however, it may be more advantageous 
for the client to send data to the server which the server 
can then evaluate. For example, the policy enforced by the 
server may be modified to require an updated anti-virus 
release (e.g., to require clients to download a new set of 
virus definitions in response to a virus emergency in 
which a new virus is spreading rapidly). In this case, it is 
generally inefficient to require each client device to down- 
load an entirely new policy just because the anti-virus rule 
has been updated. Instead, the virus information is pro- 
vided to the server, enabling the server to determine 
which clients are (and are not) in compliance with the 



anti-virus rule of the policy. The server may then take ac- 
tion based on this information. For example, in the case 
of a virus emergency, the server may "restrict" connected 
clients that are not in compliance with the anti-virus rule 
and send them a message informing them that they need 
to update their anti-virus software and/or definition files. 
As illustrated by the above examples, the security evalua- 
tion may be performed at the client or at the server. Alter- 
natively, security compliance may be evaluated by a sepa- 
rate security evaluation service as previously described. 
[0 1 66] Example of client compliance evaluation 

[0167] when the client has received a compliance challenge in 

the form of a CMP packet, it can read the packet to deter- 
mine what kind of compliance is required. If compliance 
only requires the presence of a security client, this can 
readily be determined by loading a TrueVector engine API 
library (a loadable library called "vspubapi.dll") and calling 
an API function to determine if the security client is run- 
ning. Loading the TrueVector engine API library is accom- 
plished using the standard Windows "LoadLibrary" func- 
tion. However, the following "CheckCodeSignature" func- 
tion checks the validity of the API library before loading it: 

[0168] i; BOOL TriggerlntegrityClient::CheckCodeSignature(const 



char* 

szFileName) 

2:{ 

3: int iLen; 

4: int iWLen; 

5: WCHAR* szwTVFile; 

6: WIN_TRUST_ACTDATA_CONTEXT_WITH_SUBJECT trust 
Data; 

7: WIN_TRUST_SUBJECT_FILE trustFile; 

8: GUID guidAction = WIN_SPUB_ACTION_PUBLISHED_SOF 

TWARE; 

9: GUID guidSubjectPelmage = WIN_TRUST_SUBJTYPE_PE_ 
IMAGE; 

10: BOOL bResult = FALSE; 
11: 

12: if (IhFileWVT) 

13: hFileWVT = Load Li brary(WVT_FI LE_NAM E); 
14: 

15: if (hFileWVT) 
16: { 

17: if (IpWinVerifyTrust) 

18: pWinVerifyTrust = (PWINVERIFYTRUST)GetProcAdd 
ress(hFileWVT, 



WVT_FUNC_NAME); 

19: if (pWinVerifyTrust) 

20: { 

21: // convert file path to widechar* for WinVerifyTrus 
t() 

22: iLen = strlen(szFileName); 

23: iWLen = (iLen + 1) * sizeof(WCHAR); 

24: szwTVFile = (WCHAR*)malloc(iWLen); 

25: if (szwTVFile) 

26: { 

27: ZeroMemory(szwTVFile, iWLen); 

28: mbstowcs(szwTVFile, szFileName, iLen); 

29: 

30: // fill out WinVerifyTrustO data structures 

31: trustFile.lpPath = szwTVFile; 

32: trustFile.hFile = INVALID_HANDLE_VALUE; 

33: 

34: trustData.hClientToken = NULL; 

35: trustData.SubjectType = &guidSubjectPelmage; 

36: trustData.Subject = &trustFile; 

37: 

38: // Call WinVerifyTrustO 

39: bResult = pWi n Ve rifyTru st((H WN D) I N VALI D_ H AN 



DLE_ VALUE, 
&guidAction, 

40: &trustData) == ERROR.SUCCESS; 

41: free(szwTVFile); 
42: } 
43: } 
44: } 

45: return bResult; 
46: } 

[0169] The above function checks the code signature of a file 
(e.g., the TrueVector API library file) before the file is 
loaded. If the function returns "TRUE", then the file is safe 
to be loaded using the standard Windows "LoadLibraryO" 
function. 

[0170] After the TrueVector engine API file has been validated 

and loaded, the following "AreYouThereO" function of the 
TrueVector API library checks for the presence of the 
TrueVector engine: 

[° 171 ] 1: BOOL TriggerlntegrityClient::AreYouThere() 
2:{ 

3: int iSize = iVersionBufferSize; 
4: 

5: typedef BOOL (__stdcall *MYPROC)( LPSTR szVersion, 



INT* size); 

6: MYPROC pfunc; 

7: if((hTVLibrary ! = NULL) && 

8: ((pfunc = (MYPROC) CetProcAddress(hTVLibrary,"tvls 

TvRunning")) 

!=NULL)) 

9: { 

10: BOOL retVal = pfunc(szTvVersion, &iSize); 
11: if (iSize > iVersionBufferSize) 
12: { 

13: delete [] szTvVersion; 

14: szTvVersion = new char[iSize]; 

15: iVersionBufferSize = iSize; 

16: return pfunc(szTvVersion, &iSize); 

17: } 

18: else 

19: return retVal; 

20: } 

21: else 

22: return FALSE; 

23:} 

[0172] The above function checks to determine if the TrueVector 
engine (the client security software) is running on the 



client. If compliance only requires the presence of a secu- 
rity client, then this function can determine whether or not 
the client is in compliance. 

[0173] a security policy may also provide for additional compli- 
ance checking beyond simply detecting the presence of a 
security client. In this case, the additional security re- 
quirements are provided to the client for compliance eval- 
uation at the client. In the presently preferred embodi- 
ment, an XML description of the security requirements 
(attributes) is provided to the client in a CMP packet sent 
to the client. Although XML is used in the currently pre- 
ferred embodiment, those skilled in the art will appreciate 
that other data formats may also be used for describing 
the attributes to be evaluated. For example, this informa- 
tion could be represented in text strings or in an ASN.l 
(Abstract Syntax Notation One) file. To evaluate compli- 
ance with these security requirements at the client, the 
same initial steps described above are required to load the 
TrueVector engine API library. However, additional steps 
are required to determine if the client device (e.g., com- 
puter) is compliant with the security requirements. 

[0174] The TrueVector API library provides a "tvGetSecuri- 

tyProviderlnfo" function to obtain information about the 



current state of the client device, including information 
about the security client installed on the client device. The 
function currently returns data in the form of an XML Uni- 
code string which describes the current compliance state 
of the client as described below. The current state of the 
client computer is then compared to the requirements 
that were described in the incoming CMP packet for de- 
termining whether the client is in compliance with the se- 
curity requirements. 
[0175] The above is one example of a process that may be used 
for checking security compliance of a client device. Those 
skilled in the art will recognize that a similar compliance 
checking process can be implemented using various other 
security engines, including anti-virus, firewall, and/or 
spyware checkers. For example, an anti-virus engine can 
be used for determining if the client was in compliance 
with required anti-virus rules. As another example, a con- 
figuration checker (e.g., HfNetCheckPro from Shavlik 
Technologies of Roseville, MN) can be used to determine if 
necessary product releases, patches, or other files have 
been installed or applied at the client device. Accordingly, 
it should be understood that the above example of com- 
pliance checking using the TrueVector engine is only one 



example of a security engine or module that can be used 
for performing a compliance evaluation. 

[01 76] How compliance is described 

[0177] | n the presently preferred embodiment, compliance 

checking involves several basic data structures, which 
represent the data exchanged or evaluated by the system 
at each of the compliance evaluation steps. Note that 
while in the system of the present invention these data 
structures are usually represented as either text strings or 
XML documents, the same information could be repre- 
sented in other data formats, as desired. For instance, the 
data could be represented in ASN.l format. ASN.l, or Ab- 
stract Syntax Notation One, is an International Standards 
Organization (ISO) data representation format used to 
achieve interoperability between platforms. 

[0178] a first data structure in the presently preferred embodi- 
ment is a "reporting requirements" data structure. The re- 
porting requirements data structure contains a list of at- 
tributes that the client is required to report. A second data 
structure is a "configuration report" data structure, which 
lists the values of the required reporting parameters. The 
configuration report data structure is structured as a list 
of attributes and their values. The following is a simple 



example of a member of the configuration report data 
structure: 
[0179] i; Example: 

2: <ConfigurationReport> 

3: <provider type="zonelabs" policyMd5="" policyVersion 
="" /> 

4: <provider type="symantec.nav" datDate="2003-ll-13 
00:00:00 

-08:00" datVersion="51113w" engineVersion= ,, 4.2.0.7" 
status="notRunning" /> 
5: </ConfigurationReport> 

[0180] a third data structure is a "compliance requirements" (or 
compliance rules) data structure. The compliance rules 
data structure lists certain required values or ranges to be 
used for determining whether or not a client is in compli- 
ance with a security policy. The following definition illus- 
trates the syntax for the rules in XML: 

[° 181 ] 1: <ComplianceRules> 

2: <ComplianceRule operator="eq|lt|gt| between" 
provider="provider.name" 

3: attribute="attrib.name" operandl="valuel" operand2 
="value2" 

4: status="status_string" message="user warning messa 



ge" /> 

5: </ComplianceRules> 
[0182] Another example is as follows: 

[0183] i; <ComplianceRules> 

2: <ComplianceRule operator="ge" provider="zonelabs" 
attribute="clientVersion" 

3: operandl="5.4.2" status="status_string" message="u 
ser warning 
message" /> 

4: <ComplianceRule operator="ge" provider="symantec.n 
av" 

attribute="datVersion" 

5: operandl="8.0" status="status_string" message="us 
er warning 
message" /> 
6: </ComplianceRules> 
[0184] Another data structure of the currently preferred embodi- 
ment is a "compliance report" data structure. The compli- 
ance report data structure lists noteworthy items that 
were found by applying the compliance rules to the client 
configuration report. Several example entries in the com- 
pliance report data structure are illustrated below. The 
following is an entry indicating that the version of the se- 



curity software installed on the client is not up to date: 
[0185] i; <ComplianceReport> 

2: Compliance Status: ZoneLabs.clientVersion too low 

3: Compliance Code: non-compliant 

4: User-message: ZA_CLIENTVERSION Your client version 

is not 

up to date 

5: </ComplianceReport> 
[0186] The following is another example entry: 

[0187] i; <ComplianceReport> 

2: Compliance Status: Symantec. nav.datDate too old 

3: Compliance Code: non-compliant 

4: User-message: AV_DAT_FILE_OUT_OF_DATE Your Anti 

virus version 

must be updated 

5: </ComplianceReport> 
[0188] The above entry indicates that the virus definition file 

(e.g., .dat file) in use at the client is out of date. 
[0189] Another example entry is as follows: 

[0190] i; <ComplianceReport> 

2: Compliance Status: ZoneLabs.clientVersion update avail 
able 



3: Compliance Code: Compliant 

4: User-message: ZA_CLIENTUPGRADE An update is availa 
ble for 
your client 

5: </ComplianceReport> 
[0191] This entry indicates that although the client is compliant, 
the client is not using the most current version of the 
client security module and may wish to install an available 
update. 

[0192] | n the currently preferred embodiment, the compliance 
result is an enumerated type with one of two values. A 
value of "compliant" indicates that the client is in compli- 
ance with required elements of the security policy. A value 
of "non-compliant" indicates that the client is not in com- 
pliance with the policy. In one embodiment, the result of a 
compliance check will be equal to "non-compliant" if any 
line item in the compliance report is marked as "non- 
compliant". 

[0193] Currently, if the compliance check is performed at the 

client device, the compliance result is communicated from 
the client back to the compliance checker as a response 
message from the client to the security checker module of 
the system. In the response message, the value of "compli- 



ant" is encoded as the value zero (0), and the value of 
"non-compliant" is encoded as a non-zero value. If the 
client device sends a response message indicating that it 
is "non-compliant", the security checker program will 
generally exit and return a non-zero value (e.g., the value 
one (1)) to its caller (for example, the sub-authentication 
filter DLL). If the client device replies that it is "compliant", 
the security checker module will usually exit and return a 
zero value to its caller. As previously described, the com- 
pliance check may be performed at the client or at the 
server, or compliance may be evaluated by a separate se- 
curity evaluation service. 
[0194] while the invention is described in some detail with spe- 
cific reference to a single-preferred embodiment and cer- 
tain alternatives, there is no intent to limit the invention to 
that particular embodiment or those specific alternatives. 
Although the above discussion uses an example of check- 
ing security attributes of a client for compliance with a se- 
curity policy, the present invention may also be used to 
verify a number of other attributes of the client device 
that may be of interest. For instance, the system and 
methodology of the present invention may also check to 
ensure that required virus suppression measures or file 



integrity mechanisms are in force on a client device. Ac- 
cordingly, those skilled in the art will appreciate that 
modifications may be made to the preferred embodiment 
without departing from the teachings of the present in- 
vention. 



